NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/127

Text File | 1996-08-06 | 3.9 KB | 84 lines

Newsgroups: comp.std.c++
Path: cs.mu.OZ.AU!bounce-back
From: [e-mail] (Roger S. Morris)
Subject: Re: STL still in standard
Message-ID: <[e-mail]>
Apparently-To: [e-mail]
Originator: [e-mail]
Sender: [e-mail] (CS-Usenet)
Organization: Discrete Time Systems Corporation
References: <4dgrb4$[e-mail]> <4dd7on$[e-mail]> <[e-mail]>
X-Original-Date: Wed, 24 Jan 1996 01: 35:31 GMT
Date: Wed, 24 Jan 1996 01:40:28 GMT
Approved: [e-mail]
X-Auth: PGPMoose V1.1 PGP comp.std.c++
    iQBFAgUBMQWON+EDnX0m9pzZAQF5nwF9Fd2B6yZZ9Eh92sCnKVTckV+NxkvAvI8m
    SZfGGsbMbJ/qrP0HvFXfogu3b7wDBuEY
    =/k3y

Related to the apparent "un-object-orientedness" of STL, one problem we've
run into is the inability to gracefully store abstract objects in a container.

One solution is to wrap the object to be stored in some sort of handle.
For those who like to wrap everything in a "handle", this works well.  For
others, this is quite an inconvenience.

Another solution is to use a container of pointers-to-T.  This, however,
makes for some ugly and dangerous code.

Our solution was to create the templates ``plist'', ``pvector'',
``pset'', etc.  These are containers that meet the requirements of
``list'', ``vector'', etc., but internally use pointers instead of
actual copies of the objects.

We've extended the role of the allocator to include ``T* make_default()'' and
``T* make_copy(const T&)'' functions.  This way, a ``plist<T>'' (for example)
can meet all the requirements of a ``list<T>'', even if T lacks an actual
default ctor or a copy ctor.

Often, We've found that make_copy is defined as ``{ return t.replicate(); }'',
where ``T* replicate()'' is a virtual function for duplicating and returning a
pointer to the new copy.  We do this so often that, in our plist.h, we
have a:
   template<class T> class plistB<T> : public plist<T,p_allocatorB<T> > {...};
where ``p_allocatorB<T>'' assumes T has a ``replicate'' member function, and
that T cannot be default constructed.  Note that, due to lack of a default
constructor, plistB<T> can't do everything that list<T> can, but this is
usually not a problem.

Also, we have an p_allocatorA<T> which simply does a ``{ return new T(t); }''
for make_copy(), and a ``{ return new T; }'' for make_default().  Our
``plistA<T>'' uses this allocator (our compiler doesn't support default
template args).


We are currently adding some special iterator tags to determine if the
iterator is to one of our "p*" containers.  Using these tags, we should
be able to speed up those algorithms that move elements around within or
between containers (since moving a pointer is almost always faster than
moving an object).  The "p*" container iterators offer the following
additional functions:
    T* get_p();                 // These should always be used together
    void set_p(T*);             //  "
and the "plist" (for example) offers:
    void push_back_p( T* p );                     // ``p'' is deletable
    void push_front_p( T* p );                    //  "
    iterator insert_p(iterator position, T* p );  //  "
    T* pop_back_p();                // Caller must worry about deleting
    T* pop_front_p();               //  returned value.
    T* erase_p(iterator position);  //  "
All of the above (slightly dangerous) extensions transfer "ownership" of
a deletable pointer between caller and callee.  These extensions are
primarily for use by well-tested algorithms.  The general user would
typically stick to the basic set of (safe) STL-defined routines.


Maybe by using something like this, the original poster would find
STL more OO-friendly.

--Roger Morris
---
[ comp.std.c++ is moderated.  Submission address: [e-mail].
  Contact address: [e-mail].  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]